Resource dispensers are known for dispensing resources of a service provider to a number of users of that service provider. For example, resource dispensers have been designed for use with IBM's MQSeries message queuing technology. MQSeries systems are described, for example, in the following publications available from IBM Corporation: “An Introduction to Messaging and Queuing”, IBM document number GC33-0805-01; and “MQSeries—Message Queue Interface Technical Reference”, IBM document number SC33-0850-01, both herein incorporated by reference. (IBM and MQSeries are trade marks of IBM Corporation). These message queuing systems provide one example of the type of system to which the present invention can be applied, and before discussing resource dispensers in more detail it is useful to consider briefly how these systems operate.
In an MQSeries message queuing system, a system program known as a “queue manager” provides message queuing services to a group of applications which use the queue manager to send and receive messages over a network. A number of queue managers may be provided in the network, each servicing one or more applications local to that queue manager. A message sent from one application to another is stored in a message queue maintained by the queue manager local to the receiving application until the receiving application is ready to retrieve it. Applications can retrieve messages from queues maintained by their local queue manager, and can, via the intermediary of their local queue manager, put messages on queues maintained by queue managers throughout the network. An application communicates with its local queue manager via an interface known as the MQI (Message Queue Interface). This defines a set of requests, or “calls”, that an application uses to invoke the services of the queue manager. In accordance with the MQI, an application first requests the resources which will be required for performance of a service, and, having received those resources from the queue manager, the application then requests performance of the service specifying the resources to be used. In particular, to invoke any queue manager service, an application first requires a connection to the queue manager. Thus the application first issues a call requesting a connection with the queue manager, and, in response to this call, the queue manager returns a connection handle identifying the connection to be used by the application. The application will then pass this connection handle as an input parameter when making other calls for the duration of the connection. The application also requires an object handle for each object, such as a queue, to be used in performance of the required service. Thus, the application will submit one or more calls requesting object handles for each object to be used, and appropriate object handles will be dispensed by the queue manager. All object handles supplied by the queue manager are associated with a particular connection handle, a given object handle being supplied for use by a particular connection, and hence for use together with the associated connection handle. After receiving the resources to be used, the application can issue a service request call requesting performance of a service. This call will include the connection handle and the object handle for each object to be used. In the case of retrieving a message from a queue for example, the application issues a “get message” call including its connection handle and the appropriate queue handle dispensed to the application to identify the connection and queue to the queue manager.
In general, the supply of resources by a service provider involves various processing operations, and these operations can be expensive in terms of processor time. For example, in the case of the queue manager discussed above, when a connection is requested various security checks are performed and the queue manager sets up a control block in memory relating to that connection. Similar control blocks are set up for each object handle requested under that connection. These operations represent an expensive overhead. While this overhead is incurred only once for the duration of each connection, each time an application disconnects from the queue manager, the control blocks are freed. The resources are thus given up and new resources must be created when the application next requires the queue manager's services. In systems such as this where multiple users may be accessing the service provider for short periods many times a day, the demands associated with supply of resources can be particularly onerous.
Resource dispensers are employed to alleviate the problem just described. In the message queuing scenario for example, a resource dispenser may be disposed between the queue manager and the group of applications which that queue manager serves so as to intercept communications between the two. In particular, when an application issues a disconnect call to disconnect from the queue manager, instead of forwarding this call to the queue manager, the resource dispenser simply stores the released resources in a resource pool. When an application next requests resources, appropriate handles are dispensed from the resource pool if available, thus avoiding the overhead associated with obtaining new handles from the queue manager. Clearly a new handle must be obtained from the queue manager if the resource pool does not contain an appropriate resource, but over time the resource dispenser will tend to accumulate a pool of resources sufficient to service the applications using the queue manager.
There is a particular problem with the operation of known resources dispensers in systems such as that described above. This problem is highlighted by the following simple example using the message queuing system already described by way of illustration. Suppose that two applications, Application 1 and Application 2, use the same local queue manager “QM” and that the resource pool maintained by the resource dispenser is initially empty. Application 1 uses two message queues, “Q1” and “Q2”, and Application 2 also uses two queues, “Q3” and “Q4”. When Application 1 starts running it firsts requests a connection with the queue manager using the MQSeries call MQCONN. The application then requests object handles for the queues it will use. In this example the queue handles are requested singly using the MQSeries call MQOPEN. The three resource request calls and the resource handles returned to the application can be represented as follows:
hc1=MQCONN (“QM”)
h1=MQOPEN (hc1, “Q1”)
h2=MQOPEN (hc1, “Q2”)
where hc1 is a connection handle for the queue manager QM, and h1 and h2 are object handles for the queues Q1 and Q2 respectively under this connection.
The application will then use these resources to invoke the required service. Suppose that the application retrieves a message from queue Q1 and generates a reply which it then puts in queue Q2. The application requests retrieval of the message from Q1 using the MQSeries call:
MQGET (hc1, h1)
where here, and throughout this specification, additional parameters included in the MQSeries call format have been omitted for clarity.
After receiving the message and generating a reply, the application sends the reply to queue Q2 using the MQSeries call:
MQPUT (hc1, h2)
Similarly, suppose that Application 2 retrieves a message from queue Q3 and puts a reply on queue Q4, and that handles are dispensed in response to the resource requests as follows:
hc2=MQCONN (“QM”)
h3=MQOPEN (hc2, “Q3”)
h4=MQOPEN (hc2, “Q4”)
where hc2 is a connection handle for the queue manager QM, and h3 and h4 are object handles for the queues Q3 and Q4 respectively under this connection. After each application has run once there will be six resources in the resource pool:
hc1 (for “QM”)
hc2 (for “QM”)
h1 (for “Q1”)
h2 (for “Q2”)
h3 (for “Q3”)
h4 (for “Q4”)
However, since each object handle is associated with the connection handle under which it was issued, these resources effectively fall into two groups as follows:
hc1 (for “QM”) hc2 (for “QM”)
h1 (for “Q1” under hc1) h3 (for “Q3” under hc2)
h2 (for “Q2” under hc1) h4 (for “Q4” under hc2)
Suppose now that a second instance of Application 2 runs and requests a connection handle as before. When a resource request is received the resource dispenser does not know what further resources might be requested by the application. In this case, therefore, where the resource pool contains two available connection handles, the resource dispenser is likely to dispense the first connection handle in the resource pool, namely hc1. When the application now requests an object handle for queue Q3, no suitable resource is available in the pool since there are only queue handles for queues Q1 and Q2 under hc1. Thus, the resource request must be forwarded to the queue manager to obtain a new object handle for queue Q3 under hc1. The same situation occurs when the application requests a handle for queue Q4, so that when this application disconnects from the queue manager the resource pool will be as follows:
hc1 (for “QM”) hc2 (for “QM”)
h1 (for “Q1” under hc1) h3 (for “Q3” under hc2)
h2 (for “Q2” under hc1) h4 (for “Q4” under hc2)
h5 (for “Q3” under hc1)
h6 (for “Q4” under hc1)
Thus, due to the restrictions imposed by the association between connection and object handles, the dispensing of hc1 by the resource dispenser here resulted in additional resources being obtained from the queue manager and added to the resource pool. There was, however, a suitable group of resources, i.e. hc2 and the associated queue handles h3 and h4, already available in the pool. It can be seen from extrapolation of this simple example that, in general after a long run, every connection handle will have an associated object handle for each object required by each application. In view of the overhead associated with generation of these handles in the queue manager as discussed above, this constitutes a significant waste of resources.
While the above example highlights a problem with particular reference to resource dispensing in a message queuing system, the same problem can arise in other data processing systems and further examples will be described below. The present invention addresses this problem, and can be applied to advantage where resources of a service provider are allocated to a plurality of users of the service provider in any data processing system wherein;                the resources are maintained in a resource pool when not allocated to a user; and        the resources comprise a plurality of first and second resources, each second resource being associated with a first resource for use together with the associated first resource; and        to invoke performance of a service by the service provider, a user issues a first resource request, requesting a first resource, one or more second resource requests, requesting one or more second resources, and, following receipt of the requested resources, issues a service request including the received first resource and at least one received second resource, requesting performance of the service.        